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Conventions  and  Terminology 

CONVENTIONS 

The  notation,  formatting,  and  conventions  used  in  this  Protection  Profile  are 
largely  consistent  with  those  used  in  version  2  of  the  Common  Criteria  (CC). 
Selected  presentation  choices  are  discussed  here  to  aid  the  Protection  Profile  user. 

The  CC  allows  several  operations  to  be  performed  on  functional  requirements; 
refinement,  selection,  assignment,  and  iteration  are  defined  in  paragraph  2.1.4  of 
Part  2  of  the  CC.  Each  of  these  operations  is  used  in  this  Protection  Profile. 

The  refinement  operation  is  used  to  add  detail  to  a  requirement,  and  thus 
further  restricts  a  requirement.  Refinement  of  security  requirements  is  denoted 
by  bold  text.  For  an  example,  see  FMT_SMR.l  in  this  Protection  Profile. 

The  selection  operation  is  used  to  select  one  or  more  options  provided  by  the 
CC  in  stating  a  requirement.  Selections  are  denoted  by  underlined  italicized 
text.  For  an  example,  see  FDP_RIP.l  in  this  Protection  Profile 

The  assignment  operation  is  used  to  assign  a  specific  value  to  an  unspecified 
parameter,  such  as  the  length  of  a  password.  Assignment  is  indicated  by 
showing  the  value  in  square  brackets,  [  assignment_value  ].  For  an  example, 
see  FIA_AFF.  1  in  this  Protection  Profile. 

The  iteration  operation  is  used  when  a  component  is  repeated  with  varying 
operations.  Iteration  is  denoted  by  showing  the  iteration  number  in 
parenthesis  following  the  component  identifier,  (iteration_number).  For 
example,  see  FDP_IFC  in  this  Protection  Profile. 

The  security  target  writer  operation  is  used  to  denote  points  in  which  the 
final  determination  of  attributes  is  left  to  the  security  target  writer.  Security 
target  writer  operations  are  indicated  by  the  words  {determined  by  the  security 
target  writers}  in  braces.  For  example,  see  FIA_ATD.l  in  this  Protection 
Profile. 

As  a  vehicle  for  providing  a  further  understanding  of  and  context  for  functional 
requirements,  “Requirements  Overview”  sections  have  been  selectively  added  to 
this  Protection  Profile.  When  they  appear  in  the  text,  these  overviews  precede 
either  a  component  or  set  of  components.  They  provide  a  discussion  of  the 
relationship  between  security  requirements  so  that  the  Protection  Profile  user  can 
see  why  a  component  or  group  of  components  was  chosen  and  what  effect  it  is 
expected  to  have  as  a  group  of  related  functions.  As  an  example,  see  the 
Requirements  Overview  which  precedes  the  ADV_RCR.l  assurance  component. 


IV 


Application  Notes  are  provided  to  help  the  developer,  either  to  clarify  the  intent  of 
a  requirement,  identify  implementation  choices,  or  to  define  “pass-fail”  criteria 
for  a  requirement.  For  those  components  where  Application  Notes  are 
appropriate,  the  Application  Notes  will  follow  the  requirement  component.  For 
an  example,  see  the  Application  Note  which  follows  FMT_MSA.3  in  this 
Protection  Profile. 

TERMINOLOGY 

In  the  Common  Criteria,  many  terms  are  defined  in  Section  2.3  of  Part  1.  The 
following  are  a  subset  of  those  definitions.  They  are  listed  here  to  aid  the  user  of 
the  Protection  Profile. 

User  —  Any  entity  (human  user  or  external  IT  entity)  outside  the  TOE  that 
interacts  with  the  TOE. 

Human  user  —  Any  person  who  interacts  with  the  TOE. 

External  IT  entity  —  Any  IT  product  or  system,  untrusted  or  trusted,  outside 
of  the  TOE  that  interacts  with  the  TOE. 

Role  —  A  predefined  set  of  rules  establishing  the  allowed  interactions  between 
a  user  and  the  TOE. 

Identity  —  A  representation  (e.g.  a  string)  uniquely  identifying  an  authorized 
user,  which  can  either  be  the  full  or  abbreviated  name  of  that  user  or  a 
pseudonym. 

Authentication  data  —  Information  used  to  verify  the  claimed  identity  of  a 
user. 

Erom  the  above  definitions  given  by  the  CC,  the  following  terms  can  be  derived: 

Authorized  external  IT  entity  -  Any  IT  product  or  system,  outside  the  scope 
of  the  TOE  that  may  administer  the  security  parameters  of  the  TOE.  Such 
entities  are  not  subject  to  any  access  control  requirements  once  authenticated 
to  the  TOE  and  are  therefore  trusted  to  not  compromise  the  security  policy 
enforced  by  the  TOE. 

Authorized  Administrator  -  A  role  which  human  users  may  be  associated 
with  to  administer  the  security  parameters  of  the  TOE.  Such  users  are  not 
subject  to  any  access  control  requirements  once  authenticated  to  the  TOE  and 
are  therefore  trusted  to  not  compromise  the  security  policy  enforced  by  the 
TOE. 


Document  Organization 


Section  1  is  the  introductory  material  for  the  Protection  Profile. 

Section  2  provides  a  general  definition  for  application-filter  firewalls. 

Section  3  is  a  discussion  of  the  expected  environment  for  the  firewall,  in 
particular  the  assumptions  that  must  be  true  about  aspects  such  as  physical, 
personnel,  and  connectivity  conditions.  This  section  then  defines  the  set  of  threats 
that  are  to  be  addressed  by  either  the  technical  countermeasures  implemented  in 
the  firewall’s  hardware  and  software,  or  through  the  environmental  controls. 

Section  4  defines  the  security  objectives  for  both  the  firewall  and  the  environment 
in  which  the  firewall  resides. 

Section  5  contains  the  functional  and  assurance  requirements  derived  from  the 
Common  Criteria,  Part  2  and  Part  3,  respectively,  that  must  be  satisfied  by  the 
firewall. 

Section  6  provides  a  rationale  to  explicitly  demonstrate  that  the  IT  security 
objectives  satisfy  the  threats.  The  section  then  explains  how  the  set  of 
requirements  are  complete  relative  to  the  objectives;  that  each  security  objective 
is  addressed  by  one  or  more  relevant  component  requirements. 

Appendix  A  provides  a  list  of  relevant  vulnerabilities  against  which  Protection 
Profile  compliant  products  must  be  checked. 

References  are  provided  as  background  material  for  further  investigation  by 
interested  users  of  the  Protection  Profile. 

Acronyms  are  provided  to  facilitate  comprehension  of  frequently  used  terms. 
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Application-Level  Firewall  Protection  Profile 


1 _ PROTECTION  PROFILE  (PP)  INTRODUCTION 

1.1  PP  IDENTIFICATION 

1  Title:  U.  S.  Department  of  Defense  Application-Level  Firewall  Protection  Profile 
for  Basic  Robustness  Environments 

2  Sponsor:  National  Security  Agency  (NSA) 

3  Authors:  Wayne  Jansen,  NSA;  Jack  Walsh,  NSA;  Kathy  V.  Dolan,  NSA;  Patricia 
A.  Wright,  NSA;  Rita  R.  Montequin,  NSA 

4  CC  Version:  CC  Version  2.1 

5  Registration:  <to  be  provided  upon  registration> 

6  PP  Version:  Version  1.0,  dated  June  2000 

7  Keywords:  information  flow  control,  firewall,  network  security,  proxy  server, 
application  gateway,  protection  profile 

1.2  PP  OVERVIEW 

8  This  Application  Ixvel  Firewall  Protection  Profile  defines  the  minimum  security 
requirements  for  firewalls  used  by  U.  S.  Government  organizations  handling 
unclassified  information  in  a  low-risk  environment.  Firewalls  may  consist  of  one 
or  more  devices  that  act  as  part  of  an  organization’s  overall  security  defense  by 
isolating  an  organization’s  internal  network  from  the  Internet  or  other  external 
networks.  The  Protection  Profile  defines  the  assumptions  about  the  security 
aspects  of  the  environment  in  which  the  firewall  will  be  used,  defines  the  threats 
that  are  to  be  addressed  by  the  firewall,  defines  implementation-independent 
security  objectives  of  the  firewall  and  its  environment,  defines  the  functional  and 
assurance  requirements  to  meet  those  objectives,  and  provides  a  rationale 
demonstrating  how  the  requirements  meet  the  security  objectives. 

1.3  RELATED  PROTECTION  PROFILES 

9  U.S.  Government  Traffic-Filter  Firewall  Protection  Profile  for  Fow-Risk 
Environments  [2]. 
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TARGET  OF  EVALUATION  (TOE)  DESCRIPTION 


10  The  purpose  of  a  firewall  is  to  provide  controlled  and  audited  access  to  services, 
both  from  inside  and  outside  an  organization’s  network,  by  allowing,  denying, 
and/or  redirecting  the  flow  of  data  through  the  firewall.  Although  there  are  a 
number  of  firewall  architectures  and  technologies,  firewalls  basically  fall  into  two 
major  categories:  traffic-filter  and  application-level  firewalls.  This  Protection 
Profile  specifies  the  minimum- security  requirements  for  TOEs  composed  of  an 
application-level  firewall. 

1 1  The  TOE  mediates  information  flows  between  clients  and  servers  located  on 
internal  and  external  networks  governed  by  the  TOE.  TOEs  must  employ 
proxies  to  screen  information  flows.  Proxy  servers  on  the  TOE,  for  services  such 
as  ETP  and  Telnet,  require  authentication  at  the  TOE  by  client  users  before 
requests  for  such  services  can  be  authorized.  Thus,  only  valid  requests  are 
relayed  by  the  proxy  server  to  the  actual  server  on  either  an  internal  or  external 
network. 

12  TOEs  meeting  this  Protection  Profile  additionally  impose  traffic-filtering  controls 
on  information  flows  mediated  by  the  TOE.  Information  flows  between  clients 
and  servers  according  to  the  site’s  security  policy  rules.  By  default,  these  security 
policy  rules  deny  all  inbound  and  outbound  information  flows.  Only  an 
authorized  administrator  has  the  authority  to  change  the  security  policy  rules. 

13  Users  of  the  TOE  consist  of  human  users  and  host-like  entities,  called  external  IT 
entities.  Human  users  may  or  may  not  be  associated  with  the  single  role  on  the 
TOE  for  authorized  administrators.  If  the  information  flow  security  policy  rules 
permit  human  users  (who  are  not  authorized  administrators)  on  an  internal  or 
external  network  to  send  and  receive  information  to  ETP  or  Telnet  servers  on  an 
external  or  internal  network,  respectively,  such  users  will  have  to  be  identified 
and  authenticated  (using  a  single-use  authentication  mechanism)  by  the  TOE 
before  information  is  relayed  by  the  proxy  server  on  the  TOE  to  the  ETP  or  Telnet 
server.  Of  the  human  users,  only  authorized  administrators  may  access  the  TOE 
through  remote  means  from  an  internal  or  external  network.  If  an  authorized 
administrator  accesses  the  TOE  remotely,  and  after  successful  identification  and 
authentication  (using  a  single-use  authentication  mechanism),  a  channel  using 
DES  encryption  with  securely  generated  and  distributed  key  values  must  be  used. 
In  addition  to  remote  access,  and  after  successful  identification  and 
authentication,  authorized  administrators  may  access  the  TOE  through  local 
means  without  encryption,  such  as  through  a  console  (that  may  be  included  as  part 
of  the  TOE).  Though  not  recommended,  the  human  users  who  are  not  authorized 
administrators  may  identify  and  authenticate  from  a  local  console  to  use  non¬ 
security  functions  on  the  TOE.  The  only  security  functions  available  to  human 
users  who  are  not  authorized  administrators  are  the  controlled  usage  of  the 
identification  and  authentication  functions. 
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10  External  IT  entities  sending  information  through  the  TOE  do  not  have  to  be 
identified  and  authentieated,  unless  those  funetions  are  supported  by  the 
underlying  service  (e.g.,  ETP).  However,  external  IT  entities  attempting  to  send 
information  to  the  TOE  must  always  be  identified  and  authenticated.  Those 
external  IT  entities  that  are  successfully  identified  and  authenticated  (using  a 
single-use  authentication  mechanism)  are  authorized  external  IT  entities.  This 
subset  of  the  external  IT  entities  are  permitted  to  perform  a  limited  number  of 
security  functions.  They  are  “authorized”  to  violate  the  TSP  in  a  well  understood 
and  permitted  manner.  A  router  sending  routing  table  updates  to  the  TOE,  serves 
as  an  example  of  an  authorized  external  IT  entity.  This  router  would  identify 
itself  to  the  TOE  and  then  use  a  single-use  authentication  mechanism  to 
authenticate.  The  TOE  would  then  accept  routing  table  updates  from  the 
authorized  external  IT  entity.  There  are  no  requirements  mandating  authorized 
external  IT  entities. 

1 1  Audit  trail  data  is  stamped  with  a  dependable  date  and  time  when  recorded.  Audit 
events  include  modifications  to  the  group  of  users  associated  with  the  authorized 
administrator  role,  all  use  of  the  identification  and  authentication  mechanisms 
(including  any  attempted  reuse  of  authentication  data),  all  information  flow 
control  decisions  made  by  the  TOE  according  to  the  security  policy  rules,  and  the 
use  of  all  security  functions.  If  the  audit  trail  becomes  filled,  then  the  only 
auditable  events  that  may  be  performed  are  those  performed  by  the  authorized 
administrator.  The  TOE  includes  tools  to  perform  searching  and  sorting  on  the 
collected  audit  trail  data  according  to  attributes  of  the  data  recorded  and  ranges  of 
some  of  those  attributes. 
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TOE  SECURITY  ENVIRONMENT 


12  Protection  Profile-compliant  TOEs  are  intended  to  be  used  either  in  environments 
in  which,  at  most,  sensitive  but  unclassified  information  is  processed,  or  the 
sensitivity  level  of  information  in  both  the  internal  and  external  networks  is 
equivalent. 

13  For  all  Federal  agencies,  including  Department  of  Defense  agencies,  for  the  use  of 
cryptographic  modules  in  the  protection  of  sensitive  but  unclassified  information, 
compliance  with  FIPS  PUB  140-1  is  required'.  FIPS  PUB  140-1  defines  security 
requirements  for  cryptographic  modules.  A  cryptographic  module  is  that  part  of  a 
system  or  application  that  provides  cryptographic  services  such  as  encryption, 
authentication,  or  electronic  signature  generation  and  verification.  Products  and 
systems  compliant  with  this  Protection  Profile  are  expected  to  utilize 
cryptographic  modules  for  remote  administration  compliant  with  this  FIPS  PUB. 

3.1  ASSUMPTIONS 

14  The  following  conditions  are  assumed  to  exist  in  the  operational  environment. 

A.PHYSEC  The  TOE  is  physically  secure. 

A.FOWEXP  The  threat  of  malicious  attacks  aimed  at  discovering  exploitable  vulnerabilities  is 
considered  low. 

A.GENPUR  There  are  no  general-purpose  computing  capabilities  (e.g.,  the  ability  to  execute 
arbitrary  code  or  applications)  and  storage  repository  capabilities  on  the  TOE. 

A.PUBFIC  The  TOE  does  not  host  public  data. 

A.NOEVIF  Authorized  administrators  are  non-hostile  and  follow  all  administrator  guidance; 
however,  they  are  capable  of  error. 

A.SINGEN  Information  can  not  flow  among  the  internal  and  external  networks  unless  it 
passes  through  the  TOE. 

A.DIRECT  Human  users  within  the  physically  secure  boundary  protecting  the  TOE  may 
attempt  to  access  the  TOE  from  some  direct  connection  (e.g.,  a  console  port)  if 
the  connection  is  part  of  the  TOE. 


See  FIPS-PUB  140-1  for  the  schedule  by  which  all  cryptographic  modules  used  by  Federal  agencies 
must  meet  the  provisions  of  this  standard. 
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A.NOREMO 

A.REMACC 

3.2 

15 

3.2.1 

16 

T.NOAUTH 

T.REPEAT 

T.REPEAY 

T.ASPOOE 

T.MEDIAT 

T.OEDINE 

T.PROCOM 

T.AUDACC 


Human  users  who  are  not  authorized  administrators  can  not  access  the  TOE 
remotely  from  the  internal  or  external  networks. 

Authorized  administrators  may  access  the  TOE  remotely  from  the  internal  and 
external  networks. 

THREATS 

The  following  threats  are  addressed  either  by  the  TOE  or  the  environment. 

Threats  Addressed  by  the  TOE 

The  threats  discussed  below  are  addressed  by  Protection  Profile-compliant  TOEs. 
The  threat  agents  are  either  unauthorized  persons  or  external  IT  entities  not 
authorized  to  use  the  TOE  itself. 

An  unauthorized  person  may  attempt  to  bypass  the  security  of  the  TOE  so  as  to 
access  and  use  security  functions  and/or  non- security  functions  provided  by  the 
TOE. 

An  unauthorized  person  may  repeatedly  try  to  guess  authentication  data  in  order 
to  use  this  information  to  launch  attacks  on  the  TOE. 

An  unauthorized  person  may  use  valid  identification  and  authentication  data 
obtained  to  access  functions  provided  by  the  TOE. 

An  unauthorized  person  on  an  external  network  may  attempt  to  by-pass  the 
information  flow  control  policy  by  disguising  authentication  data  (e.g.,  spoofing 
the  source  address)  and  masquerading  as  a  legitimate  user  or  entity  on  an  internal 
network. 

An  unauthorized  person  may  send  impermissible  information  through  the  TOE 
which  results  in  the  exploitation  of  resources  on  the  internal  network. 

Because  of  a  flaw  in  the  TOE  functioning,  an  unauthorized  person  may  gather 
residual  information  from  a  previous  information  flow  or  internal  TOE  data  by 
monitoring  the  padding  of  the  information  flows  from  the  TOE. 

An  unauthorized  person  or  unauthorized  external  IT  entity  may  be  able  to  view, 
modify,  and/or  delete  security  related  information  that  is  sent  between  a  remotely 
located  authorized  administrator  and  the  TOE. 

Persons  may  not  be  accountable  for  the  actions  that  they  conduct  because  the 
audit  records  are  not  reviewed,  thus  allowing  an  attacker  to  escape  detection. 
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An  unauthorized  person  may  read,  modify,  or  destroy  security  critical  TOE 
configuration  data. 

An  unauthorized  person  may  cause  audit  records  to  be  lost  or  prevent  future 
records  from  being  recorded  by  taking  actions  to  exhaust  audit  storage  capacity, 
thus  masking  an  attackers  actions. 

The  threat  of  malicious  attacks  aimed  at  discovering  exploitable  vulnerabilities  is 
considered  low. 

Threat  to  be  Addressed  by  Operating  Environment 

The  threat  possibility  discussed  below  must  be  countered  by  procedural  measures 
and/or  administrative  methods. 

The  TOE  may  be  inadvertently  configured,  used,  and  administered  in  an  insecure 
manner  by  either  authorized  or  unauthorized  persons. 

ORGANIZATIONAL  SECURITY  POLICIES 

Federal  agencies  are  required  to  protect  sensitive  but  unclassified  information 
with  cryptography.  Products  and  systems  compliant  with  this  Protection  Profile 
are  expected  to  utilize  cryptographic  modules  for  remote  administration  compliant 
with  FIPS  PUB  140-1  (level  1). 

Triple  DES  encryption  (as  specified  in  FIPS  46-3  [3])  must  be  used  to  protect 
remote  administration  functions,  and  the  associated  cryptographic  module  must 
comply,  at  a  minimum,  with  FIPS  I40-I  (level  1)  [5]. 
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SECURITY  OBJECTIVES 


4.1 
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INFORMATION  TECHNOLOGY  (IT)  SECURITY 
OBJECTIVES 

The  following  are  the  IT  security  objectives  for  the  TOE: 

The  TOE  must  uniquely  identify  and  authenticate  the  claimed  identity  of  all  users, 
before  granting  a  user  access  to  TOE  functions  or,  for  certain  specified  services, 
to  a  connected  network. 

The  TOE  must  prevent  the  reuse  of  authentication  data  for  users  attempting  to 
authenticate  to  the  TOE  from  a  connected  network. 

The  TOE  must  mediate  the  flow  of  all  information  between  clients  and  servers 
located  on  internal  and  external  networks  governed  by  the  TOE,  and  must  ensure 
that  residual  information  from  a  previous  information  flow  is  not  transmitted  in 
any  way. 

Upon  initial  start-up  of  the  TOE  or  recovery  from  an  interruption  in  TOE  service, 
the  TOE  must  not  compromise  its  resources  or  those  of  any  connected  network. 

The  TOE  must  protect  the  confidentiality  of  its  dialogue  with  an  authorized 
administrator  through  encryption,  if  the  TOE  allows  administration  to  occur 
remotely  from  a  connected  network. 

The  TOE  must  protect  itself  against  attempts  by  unauthorized  users  to  bypass, 
deactivate,  or  tamper  with  TOE  security  functions. 

The  TOE  must  provide  a  means  to  record  a  readable  audit  trail  of  security-related 
events,  with  accurate  dates  and  times,  and  a  means  to  search  and  sort  the  audit 
trail  based  on  relevant  attributes. 

The  TOE  must  provide  user  accountability  for  information  flows  through  the  TOE 
and  for  authorized  administrator  use  of  security  functions  related  to  audit. 

The  TOE  must  provide  functionality  that  enables  an  authorized  administrator  to 
use  the  TOE  security  functions,  and  must  ensure  that  only  authorized 
administrators  are  able  to  access  such  functionality. 

The  TOE  must  provide  the  means  for  an  authorized  administrator  to  control  and 
limit  access  to  TOE  security  functions  by  an  authorized  external  IT  entity. 

The  TOE  must  be  structurally  tested  and  shown  to  be  resistant  to  obvious 
vulnerabilities. 
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Eor  a  detailed  mapping  between  threats  and  the  IT  security  objectives  listed 
above,  see  section  6.1  of  the  Rationale. 

SECURITY  OBJECTIVES  FOR  THE  ENVIRONMENT 

All  of  the  assumptions  stated  in  section  3.1  are  considered  to  be  security 
objectives  for  the  environment.  The  following  are  the  Protection  Profile  non-IT 
security  objectives,  which,  in  addition  to  those  assumptions,  are  to  be  satisfied 
without  imposing  technical  requirements  on  the  TOE.  That  is,  they  will  not 
require  the  implementation  of  functions  in  the  TOE  hardware  and/or  software. 
Thus,  they  will  be  satisfied  largely  through  application  of  procedural  or 
administrative  measures. 

The  TOE  is  physically  secure. 

The  threat  of  malicious  attacks  aimed  at  discovering  exploitable  vulnerabilities  is 
considered  low. 

There  are  no  general-purpose  computing  capabilities  (e.g.,  the  ability  to  execute 
arbitrary  code  or  applications)  and  storage  repository  capabilities  on  the  TOE. 

The  TOE  does  not  host  public  data. 

Authorized  administrators  are  non-hostile  and  follow  all  administrator  guidance; 
however,  they  are  capable  of  error. 

Information  can  not  flow  among  the  internal  and  external  networks  unless  it 
passes  through  the  TOE. 

Human  users  within  the  physically  secure  boundary  protecting  the  TOE  may 
attempt  to  access  the  TOE  from  some  direct  connection  (e.g.,  a  console  port)  if 
the  connection  is  part  of  the  TOE. 

Human  users  who  are  not  authorized  administrators  can  not  access  the  TOE 
remotely  from  the  internal  or  external  networks. 

Authorized  administrators  may  access  the  TOE  remotely  from  the  internal  and 
external  networks. 

The  TOE  must  be  delivered,  installed,  administered,  and  operated  in  a  manner 
that  maintains  security. 

Authorized  administrators  are  trained  as  to  establishment  and  maintenance  of 
security  policies  and  practices. 

Eor  a  detailed  mapping  between  threats,  assumptions,  and  the  non-TT  security 
objectives  listed  above  see  section  6.2  of  the  Rationale. 
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IT  SECURITY  REQUIREMENTS 


5.1  TOE  SECURITY  REQUIREMENTS 

23  This  section  provides  functional  and  assurance  requirements  that  must  be  satisfied 
by  a  Protection  Profile-compliant  TOE.  These  requirements  consist  of  functional 
components  from  Part  2  of  the  CC  and  an  Evaluation  Assurance  Eevel  (EAE) 
containing  assurance  components  from  Part  3  of  the  CC. 

5.1.1  TOE  Security  Requirements 

24  The  functional  security  requirements  for  this  Protection  Profile  consist  of  the 
following  components  from  Part  2  of  the  CC,  summarized  in  the  following  table. 


Functional  Components 

PMT_SMR.l 

Security  roles 

PIA_ATD.l 

User  attribute  definition 

PIA_UID.2 

User  identification  before  any  action 

PIA_APE.l 

Authentication  failure  handling 

PIA_UAU.5 

Multiple  authentication  mechanisms 

EDPJEC.l 

Subset  information  flow  control  (1) 

EDPJEC.l 

Subset  information  flow  control  (2) 

EDPJEE.l 

Simple  security  attributes  (1) 

EDPJEE.l 

Simple  security  attributes  (2) 

PMT_MSA.l 

Management  of  security  attributes  (1) 

PMT_MSA.l 

Management  of  security  attributes  (2) 

PMT_MSA.l 

Management  of  security  attributes  (3) 

PMT_MSA.l 

Management  of  security  attributes  (4) 

PMT_MSA.3 

Static  attribute  initialization 

PMT_MTD.l 

Management  of  TSE  data  (1) 

PMT_MTD.l 

Management  of  TSE  data  (2) 

PMT_MTD.2 

Management  of  limits  on  TSE  data 

PDP_RIP.l 

Subset  residual  information  protection 

PCS_COP.l 

Cryptographic  operation 
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Functional  Components 

FPT_RVM.l 

Non-bypassability  of  the  TSP 

FPT_SEP.l 

TSE  domain  separation 

FPT_STM.l 

Reliable  time  stamps 

FAU_GEN.l 

Audit  data  generation 

FAU_SAR.l 

Audit  review 

FAU_SAR.3 

Selectable  audit  review 

FAU_STG.l 

Protected  audit  trail  storage 

FAU_STG.4 

Prevention  of  audit  data  loss 

FMT_MOF.l 

Management  of  security  functions  behavior  (1) 

FMT_MOF.l 

Management  of  security  functions  behavior  (2) 

Table  5.1  -  Functional  Requirements 


25  The  statement  of  the  TOE  security  requirements  must  include  a  minimum  strength 
level  for  the  TOE  security  functions  realized  by  a  probablistic  or  permutational 
mechanism.  In  the  case  of  this  protection  profile,  this  minimum  level  shall  be 
SOE-basic.  Eor  a  rationale  for  this  selected  level,  see  section  6.3  of  the  rationale. 

26  Specific  strength  of  function  metrics  are  defined  for  the  following  requirement: 

27  EIA_UAU.5  -  Strength  of  Eunction  shall  be  demonstrated  for  the  single-use  and 
password  authentication  mechanism(s)  by  demonstrating  compliance  with  the 
“Statistical  random  number  generator  tests”  found  in  section  4.11.1  of  EIPS  PUB 
140-1  [4]  and  the  “Continuous  random  number  generator  test”  found  in  section 
4.1 1.2  of  PIPS  PUB  140- 1  [4].  Strength  of  function  shall  be  demonstrated  for  the 
password  authentication  mechanism  such  that  the  probability  that  authentication 
data  can  be  guessed  is  no  greater  than  one  in  two  to  the  fortieth  (2^40).  The 
single-use  and  password  authentication  mechanisms  must  demonstrate  SOE-basic, 
as  defined  in  Part  1  of  the  CC. 

28  The  following  paragraphs  are  intended  to  clarify  why  the  functional  components 
in  this  Protection  Profile  are  presented  in  the  order  outlined  in  Table  5.1. 
PMT_SMR.  1  is  the  first  component  because  it  defines  the  authorized 
administrator  role,  which  appears  in  a  number  of  the  components  that  follow. 

29  The  class  PIA  components  are  listed  after  PMT_SMR.l.  They  describe  the 
identification  and  authentication  policy  that  all  users,  both  human  users  and 
external  IT  entities,  must  abide  by  before  being  able  to  use  other  TOE  functions. 

30  The  order  of  the  class  PIA  components  was  chosen  on  the  following  basis.  Since 
users  are  already  defined  in  the  Terminology  section  on  page  vi,  the  Protection 
Profile  reader  is  introduced  in  component  PIA_ATD.l  to  their  security  attributes. 
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The  next  component,  FIA_UID.2,  forces  users  to  identify  themselves  to  the  TOE 
using  the  user  security  attributes  of  component  FIA_ATD.l  before  further  actions 
take  place.  Then,  component  FIA_AFL.  1  describes  what  results  if  the  user  fails 
to  authenticate  after  some  settable  number  of  attempts.  Fastly,  component 
FIA_UAU.5  discusses  when  authentication  mechanisms  must  be  used. 

31  There  are  two  information  flow  control  SFPs,  and  they  are  defined  after  the  class 

FIA  components  in  FDP_IFC.l.  Then  the  policy  rules  which  must  be  enforced  as 
well  as  the  attributes  of  the  entities  defined  in  FDP_IFC.l  are  written  in 
FDP_IFF.l.  Next,  the  management  of  the  attributes  in  FDP_IFF.l  are  specified  in 
FMT_MSA.1(1),  FMT_MSA.1(2),  FMT_MSA.1(3)  and  FMT_MSA.1(4). 

Component  FMT_MSA.3,  which  FDP_IFF.l  depends  on,  follows.  As  part  of  the 
installation  and  start-up  of  the  TOE,  FMT_MSA.3  mandates  a  default  deny  policy 
which  permits  no  information  to  flow  through  the  TOE.  FMT_MTD.1(1), 
FMT_MTD.1(2),  and  FMT_MTD.2  define  the  management  of  TSF  data. 
FDP_RIP.l  is  listed  next,  ensuring  that  resources  are  cleared  before  being 
allocated  to  hold  packets  of  information  at  the  TOE. 

32  Component  FCS_COP.l  is  a  conditional  requirement.  If  the  developer  allows 
administration  from  a  remote  location  outside  the  physically  protected  TOE,  then 
evaluation  against  this  Protection  Profile  shall  require  the  TOE  to  meet  this 
component.  FCS_COP.l  defines  a  cryptographic  algorithm  as  well  as  the  key 
size  that  must  be  used.  The  cryptographic  module  must  be  FIPS  PUB  140- 1 
compliant  for  the  reasons  stated  in  Section  3. 

33  Components  dealing  with  the  protection  of  trusted  security  functions  come  next. 
These  include  components  FPT_RVM.l  and  FPT_SEP.l. 

34  Since  FAU_GEN.l  requires  recording  the  time  and  date  when  audit  events  occur, 
it  follows  the  FPT_STM.l  component  that  alerts  developers  that  an  accurate  time 
and  date  must  be  maintained  on  the  TOE.  The  class  FAU  requirements  follow  to 
define  the  audit  security  functions  which  must  be  supported  by  the  TOE. 
FAU_GEN.l  is  the  first  audit  component  listed  because  it  depicts  all  the  events 
that  must  be  audited,  including  all  the  information  which  must  be  recorded  in 
audit  records.  The  remainder  of  the  class  FAU  components  ensure  that  the  audit 
records  can  be  read  (component  FAU_SAR.l),  searched  and  sorted  (component 
FAU_SAR.3),  and  protected  from  modification  (FAU_STG.l).  Easily, 
FAU_STG.4  ensures  that  the  TOE  is  capable  of  preventing  auditable  actions,  not 
taken  by  an  authorized  administrator,  from  occurring  in  the  event  that  the  audit 
trail  becomes  full. 

35  The  last  component  in  the  profile  is  FMT_MOF.l.  It  appears  last  because  it  lists 
all  the  functions  to  be  provided  by  the  TOE  for  use  only  by  the  authorized 
administrator.  Almost  all  of  these  functions  are  based  on  components  which 
precede  it.  Thus  it  is  listed  last. 
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FMT_SMR.  1  Security  roles 

36  FMT_SMR.1.1  -  The  TSF  shall  maintain  the  role  [authorized  administrator]. 

37  FMT_SMR.1.2  -  The  TSF  shall  be  able  to  associate  users  with  the  authorized 
administrator  role. 

FIA_ATD.  1  User  attribute  definition 

38  FIA_ATD.1.1  -  The  TSF  shall  maintain  the  following  list  of  security  attributes 
belonging  to  individual  users: 

a)  [identity; 

b)  association  of  a  human  user  with  the  authorized  administrator  role; 

c)  any  other  user  security  attributes  [to  be  determined  by  the  Security  Target 
writer(s)}]. 

FIA_UID.2  User  identification  before  any  action 

39  FIA_UID.2.1  -  The  TSF  shall  require  each  user  to  identify  itself  before  allowing 
any  other  TSF-mediated  actions  on  behalf  of  that  user. 

FIA_AFL.  1  Authentication  failure  handling 

40  FIA_AFL.1.1  -  The  TSF  shall  detect  when  [a  non-zero  number  determined  by  the 
authorized  administrator]  of  unsuccessful  authentication  attempts  occur  related  to 
[authorized  TOE  administrator  access  or  authorized  TOE  IT  entity  access]. 

41  EIA_AEE.1.2  -  When  the  defined  number  of  unsuccessful  authentication  attempts 
has  been  met  or  surpassed,  the  TSE  shall  [prevent  the  offending  user  from 
successfully  authenticating  until  an  authorized  administrator  takes  some  action  to 
make  authentication  possible  for  the  user  in  question] . 

EIA_UAU.5  Multiple  authentication  mechanisms 

42  EIA_UAU.5.1  -  The  TSE  shall  provide  [password  and  single-use  authentication 
mechanisms]  to  support  user  authentication. 

43  EIA_UAU.5.2  -  The  TSE  shall  authenticate  any  user's  claimed  identity  according 
to  the  [following  multiple  authentication  mechanism  rules: 

a)  single-use  authentication  mechanism  shall  be  used  for  authorized 
administrators  to  access  the  TOE  remotely  such  that  successful 
authentication  must  be  achieved  before  allowing  any  other  TSE- 
mediated  actions  on  behalf  of  that  authorized  administrator; 
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b)  single-use  authentication  mechanism  shall  be  used  for  authorized 
external  IT  entities  accessing  the  TOE  such  that  successful 
authentication  must  be  achieved  before  allowing  any  other  TSF- 
mediated  actions  on  behalf  of  that  authorized  external  IT  entity; 

c)  single-use  authentication  mechanism  shall  be  used  for  human  users 
sending  or  receiving  information  through  the  TOE  using  ETP  or  Telnet 
such  that  successful  authentication  must  be  achieved  before  allowing 
any  other  TSF-mediated  actions  on  behalf  of  that  human  user; 

d)  reusable  password  mechanism  shall  be  used  for  authorized 
administrators  to  access  the  TOE  via  a  directly  connected  terminal 
such  that  successful  authentication  must  be  achieved  before  allowing 
any  other  TSE-mediated  actions  on  behalf  of  that  authorized 
administrator]. 

44  Application  Note:  TOEs  that  do  not  provide  capabilities  for  authorized 
administrators  to  access  the  TOE  remotely  from  either  an  internal  or  external 
network  (i.e.,  for  remote  administration),  or  for  authorized  external  IT  entities  do 
not  have  to  make  such  functionality  available  in  order  to  satisfy  this  requirement. 
The  intent  of  this  requirement  is  not  to  require  developers  to  provide  all  such 
capabilities  and  their  associated  authentication  mechanisms.  The  requirement 
applies  to  those  developers  that  do  incorporate  such  functionality  and  intend  for  it 
to  be  evaluated. 

45  Requirements  Overview:  This  Protection  Profile  consists  of  multiple  information 
flow  control  Security  Function  Policies  (SFPs).  The  CC  allows  multiple  policies 
to  exist,  each  having  a  unique  name.  This  is  accomplished  by  iterating  FDP_IFC.l 
for  each  of  the  two  named  information  flow  control  policies.  The  first  policy 
identified  is  called  the  UNAUTHENTICATED  SEP.  The  subjects  under  control 
of  this  policy  are  external  IT  entities  on  an  internal  or  external  network  sending 
information  through  the  TOE  to  other  external  IT  entities.  The  second  policy 
identified  is  called  the  AUTHENTICATED  SEP.  The  subjects  under  control  of 
this  policy  are  human  users  on  an  internal  or  external  network  who  must  be 
authenticated  to  the  TOE.  The  information  flowing  between  subjects  in  both 
policies  is  traffic  with  attributes,  defined  in  FDP_IFF.1.1,  including  source  and 
destination  addresses.  The  rules  that  define  each  information  flow  control  SEP  are 
found  in  FDP_IFF.1.2.  Component  FDP_IFF.l  is  iterated  twice  to  correspond  to 
each  of  the  two  iterations  of  FDP_IFC.  1. 

FDP_IFC.l  Subset  information  flow  control  (1) 

46  FDPJFC.  1 . 1  -  The  TSF  shall  enforce  the  [UNAUTHENTICATED  SEP]  on: 

a)  [subjects:  unauthenticated  external  IT  entities  that  send  and  receive 
information  through  the  TOE  to  one  another; 
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b)  information:  traffic  sent  through  the  TOE  from  one  subject  to  another; 

c)  operation:  pass  information]. 
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FDP_IFC.l  Subset  information  flow  control  (2) 

47  FDPJFC.  1 . 1  -  The  TSF  shall  enforce  the  [AUTHENTICATED  SEP]  on: 

a)  [subjects:  a  human  user  or  external  IT  entity  that  sends  and  receives  ETP 
and  Telnet  information  through  the  TOE  to  one  another,  only  after  the 
human  user  initiating  the  information  flow  has  authenticated  at  the  TOE 
per  EIA_UAU.5, 

b)  information:  ETP  and  Telnet  traffic  sent  through  the  TOE  from  one 
subject  to  another; 

c)  operation:  initiate  service  and  pass  information]. 

EDP_IEE.l  Simple  security  attributes  (1)^ 

48  EDPJEE.  1 . 1  -  The  TSE  shall  enforce  the  [UNAUTHENTICATED  SEP]  based  on 
at  least  the  following  types  of  subject  and  information  security  attributes: 

a)  [subject  security  attributes: 

•  presumed  address; 

•  other  subject  security  attributes  [to  be  determined  by  the  Security 
Target  writer(s)]; 

b)  information  security  attributes: 

•  presumed  address  of  source  subject; 

•  presumed  address  of  destination  subject; 

•  transport  layer  protocol; 

•  TOE  interface  on  which  traffic  arrives  and  departs; 


The  complete  set  of  functional  elements  of  a  component  must  be  selected  for  inclusion  in  a  PP.  However, 
since  the  following  functional  elements  from  the  FDP_IFF.l  (1)  component  do  not  add  anything  significant 
to  the  PP,  they  have  been  moved  here  to  allow  for  a  clearer,  smoother  flowing  presentation  of 
FDPJFF.l(l). 

FDP_IFF.1.3  -  The  TSF  shall  enforce  the  [none], 

FDP_IFF.1.4  -  The  TSF  shall  provide  the  following  [none], 

FDP_IFF.1.5  -  The  TSF  shall  explicitly  authorize  an  information  flow  based  on  the  following  rules: 
[none]. 
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•  service; 


•  other  information  security  attributes  {to  be  determined  by  the 
Security  Target  writer(s) }  ] . 

49  FDP_IFF.1.2  -  The  TSF  shall  permit  an  information  flow  between  a  controlled 
subject  and  another  controlled  subject  via  a  controlled  operation  if  the  following 
rules  hold: 

a)  [Subjects  on  an  internal  network  can  cause  information  to  flow  through 
the  TOE  to  another  connected  network  if: 

•  all  the  information  security  attribute  values  are  unambiguously 
permitted  by  the  information  flow  security  policy  rules,  where  such 
rules  may  be  composed  from  all  possible  combinations  of  the  values  of 
the  information  flow  security  attributes,  created  by  the  authorized 
administrator; 

•  the  presumed  address  of  the  source  subject,  in  the  information, 
translates  to  an  internal  network  address; 

•  and  the  presumed  address  of  the  destination  subject,  in  the 
information,  translates  to  an  address  on  the  other  connected  network. 

b)  Subjects  on  the  external  network  can  cause  information  to  flow  through 
the  TOE  to  another  connected  network  if: 

•  all  the  information  security  attribute  values  are  unambiguously 
permitted  by  the  information  flow  security  policy  rules,  where  such 
rules  may  be  composed  from  all  possible  combinations  of  the  values  of 
the  information  flow  security  attributes,  created  by  the  authorized 
administrator; 

•  the  presumed  address  of  the  source  subject,  in  the  information, 
translates  to  an  external  network  address; 

•  and  the  presumed  address  of  the  destination  subject,  in  the 
information,  translates  to  an  address  on  the  other  connected  network.] 

50  EDP_IEE.1.6  -  The  TSE  shall  explicitly  deny  an  information  flow  based  on  the 
following  rules: 

a)  [The  TOE  shall  reject  requests  for  access  or  services  where  the 
information  arrives  on  an  external  TOE  interface,  and  the  presumed 
address  of  the  source  subject  is  an  external  IT  entity  on  an  internal 
network; 
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b)  The  TOE  shall  reject  requests  for  access  or  services  where  the  information 
arrives  on  an  internal  TOE  interface,  and  the  presumed  address  of  the 
source  subject  is  an  external  IT  entity  on  the  external  network; 

c)  The  TOE  shall  reject  requests  for  access  or  services  where  the  information 
arrives  on  either  an  internal  or  external  TOE  interface,  and  the  presumed 
address  of  the  source  subject  is  an  external  IT  entity  on  a  broadcast 
network; 

d)  The  TOE  shall  reject  requests  for  access  or  services  where  the  information 
arrives  on  either  an  internal  or  external  TOE  interface,  and  the  presumed 
address  of  the  source  subject  is  an  external  IT  entity  on  the  loopback 
network; 

e)  The  TOE  shall  reject  requests  in  which  the  subject  specifies  the  route  in 
which  information  shall  flow  en  route  to  the  receiving  subject;  and 

f)  Eor  application  protocols  supported  by  the  TOE  (e.g.,  DNS,  HTTP, 
SMTP,  and  POPS),  the  TOE  shall  deny  any  access  or  service  requests  that 
do  not  conform  to  its  associated  published  protocol  specification  (e.g., 
REC).  This  shall  be  accomplished  through  protocol  filtering  proxies  that 
are  designed  for  that  purpose. 

51  Application  Note:  Rule  f)  applies  when  an  application-level  proxy  is  provided  for 
the  following  protocols:  DNS,  HTTP,  SMTP,  and  POPS. 

PDP_IPP.  1  Simple  security  attributes  (2)^ 

52  EDPJPP.l.l  -  The  TSE  shall  enforce  the  [AUTHENTICATED  SEP]  based  on  at 
least  the  following  types  of  subject  and  information  security  attributes: 

a)  [subject  security  attributes: 

•  presumed  address; 

•  other  subject  security  attributes  [to  be  determined  by  the  Security 
Target  writer(s)}; 


The  complete  set  of  functional  elements  of  a  component  must  be  selected  for  inclusion  in  a  PP.  However, 
since  the  following  functional  elements  from  the  FDP_IFF.l  (2)  component  do  not  add  anything  significant 
to  the  PP,  they  have  been  moved  here  to  allow  for  a  clearer,  smoother  flowing  presentation  of  FDP_IFF.l 
(2). 

FDP_IFF.1.3  -  The  TSF  shall  enforce  the  [none], 

FDP_IFF.L4  -  The  TSF  shall  provide  the  following  [none], 

FDP_IFF.L5  -  The  TSF  shall  explicitly  authorize  an  information  flow  based  on  the  following  rules: 
[none]. 
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53 


b)  information  security  attributes: 

•  user  identity; 

•  presumed  address  of  source  subject; 

•  presumed  address  of  destination  subject; 

•  transport  layer  protocol; 

•  TOE  interface  on  which  traffic  arrives  and  departs; 

•  service  (i.e.,  FTP  and  Telnet); 

•  security-relevant  service  command;  and 

•  other  information  security  attributes  {to  be  determined  by  the  Security 
Target  writer(s)}]. 

FDP_IFF.1.2  -  The  TSF  shall  permit  an  information  flow  between  a  controlled 
subject  and  another  controlled  subject  via  a  controlled  operation  if  the  following 
rules  hold: 

a)  [Subjects  on  an  internal  network  can  cause  information  to  flow  through 

the  TOE  to  another  connected  network  if: 

•  the  human  user  initiating  the  information  flow  authenticates  according 
to  FIA_UAU.5; 

•  all  the  information  security  attribute  values  are  unambiguously 
permitted  by  the  information  flow  security  policy  rules,  where  such 
rules  may  be  composed  from  all  possible  combinations  of  the  values  of 
the  information  flow  security  attributes,  created  by  the  authorized 
administrator; 

•  the  presumed  address  of  the  source  subject,  in  the  information, 
translates  to  an  internal  network  address; 

•  and  the  presumed  address  of  the  destination  subject,  in  the 
information,  translates  to  an  address  on  the  other  connected  network. 

b)  Subjects  on  the  external  network  can  cause  information  to  flow  through 

the  TOE  to  another  connected  network  if: 

•  the  human  user  initiating  the  information  flow  authenticates  according 
to  FIA_UAU.5; 
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•  all  the  information  security  attribute  values  are  unambiguously 
permitted  by  the  information  flow  security  policy  rules,  where  such 
rules  may  be  composed  from  all  possible  combinations  of  the  values  of 
the  information  flow  security  attributes,  created  by  the  authorized 
administrator; 

•  the  presumed  address  of  the  source  subject,  in  the  information, 
translates  to  an  external  network  address;  and 

•  the  presumed  address  of  the  destination  subject,  in  the  information, 
translates  to  an  address  on  the  other  connected  network.] 

54  FDP_IFF.1.6  -  The  TSF  shall  explicitly  deny  an  information  flow  based  on  the 
following  rules: 

a)  [The  TOE  shall  reject  requests  for  access  or  services  where  the  information 
arrives  on  an  external  TOE  interface,  and  the  presumed  address  of  the 
source  subject  is  an  external  IT  entity  on  an  internal  network; 

b)  The  TOE  shall  reject  requests  for  access  or  services  where  the  information 
arrives  on  an  internal  TOE  interface,  and  the  presumed  address  of  the 
source  subject  is  an  external  IT  entity  on  the  external  network; 

c)  The  TOE  shall  reject  requests  for  access  or  services  where  the  information 
arrives  on  either  an  internal  or  external  TOE  interface,  and  the  presumed 
address  of  the  source  subject  is  an  external  IT  entity  on  a  broadcast 
network; 

d)  The  TOE  shall  reject  requests  for  access  or  services  where  the  information 
arrives  on  either  an  internal  or  external  TOE  interface,  and  the  presumed 
address  of  the  source  subject  is  an  external  IT  entity  on  the  loopback 
network; 

e)  The  TOE  shall  reject  requests  in  which  the  subject  specifies  the  route  in 
which  information  shall  flow  en  route  to  the  receiving  subject;  and 

f)  The  TOE  shall  reject  Telnet  or  ETP  command  requests  that  do  not 
conform  to  generally  accepted  published  protocol  definitions  (e.g.,  RECs). 
This  must  be  accomplished  through  protocol  filtering  proxies  designed  for 
that  purpose. 

55  Application  Note:  The  TOE  can  make  no  claim  as  to  the  real  address  of  any 
source  or  destination  subject,  therefore  the  TOE  can  only  suppose  that  these 
addresses  are  accurate.  Therefore,  a  “presumed  address”  is  used  to  identify  source 
and  destination  addresses.  A  “service”,  listed  in  EDP_IEE.  1.1(b),  could  be 
identified,  for  example,  by  a  source  port  number  and/or  destination  port  number. 
A  “service  command”,  also  mentioned  in  EDP_IEE.  1.1(b),  could  be  identified,  for 
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example,  in  the  case  of  the  File  Transfer  Protocol  (FTP)  service  as  an  FTP  STOR 
or  FTP  RETR. 

FMT_MSA.  1  Management  of  security  attributes  (1) 

56  FMT_MSA.1.1  (1)  -  The  TSF  shall  enforce  the  [UNAUTHENTICATED_SFP]  to 
restrict  the  ability  to  [delete  attributes  from  a  rule,  modify  attributes  in  a  rule,  add 
attributes  to  a  rule]  the  security  attributes  [listed  in  section  EDP_IEE1.1(1)]  to  [the 
authorized  administrator] . 

EMT_MSA.  1  Management  of  security  attributes  (2) 

57  EMT_MSA.  1.1(2)  -  The  TSE  shall  enforce  the  [AUTHENTIC ATED_SEP]  to 
restrict  the  ability  to  [delete  attributes  from  a  rule,  modify  attributes  in  a  rule,  add 
attributes  to  a  rule]  the  security  attributes  [listed  in  section  EDP_IEE1.1(2)]  to  [the 
authorized  administrator] . 

EMT_MSA.  1  Management  of  security  attributes  (3) 

58  EMT_MSA.1.1(3)  -  The  TSE  shall  enforce  the  [UNAUTHENTICATED_SEP]  to 
restrict  the  ability  to  delete  and  [create]  the  security  attributes  [information  flow 
rules  described  in  EDP_IEE.1(1)]  to  [the  authorized  administrator]. 

EMT_MSA.  1  Management  of  security  attributes  (4) 

59  EMT_MSA.1.1(4)  -  The  TSE  shall  enforce  the  [AUTHENTIC ATED_SEP]  to 
restrict  the  ability  to  delete  and  [create]  the  security  attributes  [information  flow 
rules  described  in  EDP_IEE.1(2)]  to  [the  authorized  administrator]. 

EMT_MSA.3  Static  attribute  initialization 

60  EMT_MSA.3.1  -  The  TSE  shall  enforce  the  [UNAUTHENTICATED_SEP  and 
AUTHENTICATED_SEP]  to  provide  restrictive  default  values  for  information 
flow  security  attributes  that  are  used  to  enforce  the  SEP. 

61  PMT_MSA.3.2  -  The  TSE  shall  allow  [the  authorized  administrator]  to  specify 
alternative  initial  values  to  override  the  default  values  when  an  object  or 
information  is  created. 

62  Application  Note:  The  default  values  for  the  information  flow  control  security 
attributes  appearing  in  EDP_IEE.l  (1)  and  EDP_IEE.l  (2)  are  intended  to  be 
restrictive  in  the  sense  that  both  inbound  and  outbound  information  is  denied  by 
the  TOE  until  the  default  values  are  modified  by  an  authorized  administrator. 
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FMT_MTD.  1  Management  of  TSF  data  (1) 

63  FMT_MTD. 1.1(1)  -  The  TSF  shall  restrict  the  ability  to  query,  modify,  delete, 
[and  assign]  the  [user  attributes  defined  in  FIA_ATD.1.1]  to  [the  authorized 
administrator]. 

FMT_MTD.  1  Management  of  TSF  data  (2) 

64  FMT_MTD.1.1(2)  -  The  TSF  shall  restrict  the  ability  to  [set]  the  [time  and  date 
used  to  form  the  timestamps  in  FPT_STM.1.1]  to  [the  authorized  administrator]. 

FMT_MTD.2  Management  of  limits  on  TSF  data 

65  FMT_MTD.2.1  -  The  TSF  shall  restrict  the  specification  of  the  limits  for  [the 
number  of  authentication  failures]  to  [the  authorized  administrator]. 

66  FMT_MTD.2.2  -  The  TSF  shall  take  the  following  actions,  if  the  TSF  data  are  at, 
or  exceed,  the  indicated  limits:  [actions  specified  in  FIA_AFL.1.2]. 

FDP_RIP.  1  Subset  residual  information  protection 

67  FDP_RIP.1.1  -  The  TSF  shall  ensure  that  any  previous  information  content  of  a 
resource  is  made  unavailable  upon  the  allocation  of  the  resource  to  [all  objects]. 

68  Application  Note:  If,  for  example,  the  TOE  pads  information  with  bits  in  order  to 
properly  prepare  the  information  before  sending  it  out  an  interface,  these  bits 
would  be  considered  a  “resource”.  The  intent  of  the  requirement  is  that  these  bits 
shall  not  contain  the  remains  of  information  that  had  previously  passed  through 
the  TOE.  The  requirement  is  met  by  overwriting  or  clearing  resources  (e.g. 
packets)  before  making  them  available  for  use. 

EC  S_C  OP .  1  Cryptographic  operation 

69  PCS_COP.l.l  -  The  TSE  shall  perform  [encryption  of  remote  authorized 
administrator  sessions]  in  accordance  with  a  specified  cryptographic  algorithm: 
[Triple  Data  Encryption  Standard  (DES)  as  specified  in  EIPS  PUB  46-3  and 
implementing  any  mode  of  operation  specified  in  PIPS  PUB  46-3  with  Keying 
Option  1  (Kl,  K2,  K3  are  independent  keys)]  and  cryptographic  key  sizes  [that 
are  192  binary  digits  in  length]  that  meet  the  following:  [PIPS  PUB  46-3  with 
Keying  Option  1  and  PIPS  PUB  140-1  (Eevel  1)]. 

70  Application  Note:  This  requirement  is  applicable  only  if  the  TOE  includes  the 
capability  for  the  authorized  administrator  to  perform  security  functions  remotely 
from  a  connected  network.  In  this  case.  Triple  DES  encryption  must  protect  the 
communications  between  the  authorized  administrator  and  the  TOE,  and  the 
associated  cryptographic  module(s)  must  comply  at  a  minimum  with  PIPS  PUB 
140-1  Eevel  1.  The  intent  of  this  requirement  is  not  for  the  evaluator  to  perform  a 
PIPS  PUB  140-1  evaluation;  rather,  the  evaluator  will  check  for  a  certificate. 
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verifying  that  the  module  did  complete  a  FIPS  PUB  140-1  evaluation. 


FPT_RVM.l  Non-bypassability  of  the  TSP 

71  FPT_RVM.1.1  -  The  TSF  shall  ensure  that  TSP  enforcement  functions  are 
invoked  and  succeed  before  each  function  within  the  TSC  is  allowed  to  proceed. 

FPT_SEP.l  TSF  domain  separation 

72  FPT_SEP.1.1  -  The  TSE  shall  maintain  a  security  domain  for  its  own  execution 
that  protects  it  from  interference  and  tampering  by  untrusted  subjects. 

73  EPT_SEP.1.2  -  The  TSE  shall  enforce  separation  between  the  security  domains  of 
subjects  in  the  TSC. 

EPT_STM.l  Reliable  time  stamps 

74  EPT_STM.1.1  -  The  TSE  shall  be  able  to  provide  reliable  time  stamps  for  its  own 
use. 

75  Application  Note:  The  word  “reliable”  in  the  above  requirement  means  that 

the  order  of  the  occurrence  of  auditable  events  is  preserved.  Reliable  time  stamps, 
which  include  both  date  and  time,  are  especially  important  for  TOEs  comprised  of 
greater  than  one  component. 

EAU_GEN.  1  Audit  data  generation 

76  EAU_GEN.1.1  -  The  TSE  shall  be  able  to  generate  an  audit  record  of  the 
following  auditable  events: 

a)  Start-up  and  shutdown  of  the  audit  functions; 

b)  All  auditable  events  for  the  not  specified  level  of  audit;  and 

c)  [the  events  listed  in  Table  5.2]. 

77  EAU_GEN.1.2  -  The  TSE  shall  record  within  each  audit  record  at  least  the 
following  information: 

a)  Date  and  time  of  the  event,  type  of  event,  subject  identity,  outcome 
(success  or  failure)  of  the  event;  and 

b)  Eor  each  audit  event  type,  based  on  the  auditable  event  definitions  of  the 
functional  components  included  in  the  PP/ST,  [information  specified  in 
column  three  of  Table  5.2]. 
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Functional 

Component 

Auditable  Event 

Additional  Audit  Record 
Contents 

FMT_SMR.l 

Modifications  to  the  group  of 
users  that  are  part  of  the 

authorized  administrator 

role. 

The  identity  of  the  authorized 
administrator  performing  the 
modification  and  the  user  identity 
being  associated  with  the 
authorized  administrator  role 

FIA_UID.2 

All  use  of  the  user 
identification  mechanism. 

The  user  identities  provided  to  the 
TOE 

FIA_UAU.5 

Any  use  of  the  authentication 
mechanism. 

The  user  identities  provided  to  the 
TOE 

FIA_AFL.l 

The  reaching  of  the  threshold 
for  unsuccessful 
authentication  attempts  and 
the  subsequent  restoration 
by  the  authorized 
administrator  of  the  users 
capability  to  authenticate. 

The  identity  of  the  offending  user 
and  the  authorized  administrator 

FDPJFF.l 

All  decisions  on  requests  for 
information  flow. 

The  presumed  addresses  of  the 
source  and  destination  subject. 

FCS_COP.l 

Success  and  failure,  and  the 
type  of  cryptographic 
operation 

The  identity  of  the  external  IT 
entity  attempting  to  perform  the 
cryptographic  operation 

FPT_STM.l 

Changes  to  the  time. 

The  identity  of  the  authorized 
administrator  performing  the 
operation 

FMT_MOF.l 

Use  of  the  functions  listed  in 
this  requirement  pertaining  to 
audit. 

The  identity  of  the  authorized 
administrator  performing  the 
operation 

Table  5.2  -  Auditable  Events 


FAU_SAR.l  Audit  review 

78  FAU_SAR.1.1  -  The  TSF  shall  provide  [an  authorized  administrator]  with  the 
capability  to  read  [all  audit  trail  data]  from  the  audit  records. 

79  FAU_SAR.1.2  -  The  TSF  shall  provide  the  audit  records  in  a  manner  suitable  for 
the  user  to  interpret  the  information. 
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FAU_SAR.3  Selectable  audit  review 


80  FAU_SAR.3.1  -  The  TSF  shall  provide  the  ability  to  perform  searches  and 

sorting  of  audit  data  based  on: 

a)  [user  identity; 

b)  presumed  subject  address; 

c)  ranges  of  dates; 

d)  ranges  of  times; 

e)  ranges  of  addresses] . 


81  Application  Note:  The  Security  Target  writer(s)  is  expected  to  describe,  as 

part  of  their  “TOE  Summary  Specification”  section,  the  capabilities  of  the  tool(s) 
used  by  the  TOE  to  perform  these  searches  and  sorts. 

EAU_STG.  1  Protected  audit  trail  storage 

82  EAU_STG.1.1  -  The  TSE  shall  protect  the  stored  audit  records  from  unauthorized 
deletion. 
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EAU_STG.1.2  -  The  TSE  shall  be  able  to  prevent  modifications  to  the  audit 
records. 


EAU_STG.4  Prevention  of  audit  data  loss 

84  PAU_STG.4. 1  -  The  TSE  shall  prevent  auditable  events,  except  those  taken  by  the 

authorized  administrator  and  [shall  limit  the  number  of  audit  records  lost]  if  the 
audit  trail  is  full. 


85  Application  Note:  The  Security  Target  writer(s)  is  expected  to  provide,  as  part 

of  their  “Security  requirements  rationale”  section,  an  analysis  of  the  maximum 
amount  of  audit  data  that  can  be  expected  to  be  lost  in  the  event  of  audit  storage 
failure,  exhaustion,  and/or  attack. 


EMT_MOE.  1  Management  of  security  functions  behavior  (1) 

86  EMT_MOE.  1.1(1)  -  The  TSE  shall  restrict  the  ability  to  enable,  disable  the 

functions: 


a)  [operation  of  the  TOE; 

b)  multiple  use  authentication  functions  described  in  EIA_UAU.5]  to  [an 
authorized  administrator] . 
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Application  Note:  By  “Operation  of  the  TOE”  in  a)  above,  we  mean  having  the 
TOE  start  up  (enable  operation)  and  shut  down  (disable  operation).  By  "multiple 
use  authentication"  in  b)  above,  we  mean  the  mangement  of  password  and  single 
use  authentication  mechanisms. 

EMT_MOE.  1  Management  of  security  functions  behavior  (2) 

88  EMT_MOE.l.l(2)  -  The  TSE  shall  restrict  the  ability  to  enable,  disable, 
determine  and  modify  the  behaviour  of  the  functions: 

a)  [audit  trail  management; 

b)  backup  and  restore  for  TSE  data,  information  flow  rules,  and  audit  trail 
data;  and 

c)  communication  of  authorized  external  IT  entities  with  the  TOE]  to  [an 
authorized  administrator] . 

89  Application  Note:  Determine  and  modify  the  behavior  of  element  c 

(communication  of  authorized  external  IT  entities  with  the  TOE)  is  intended  to 
cover  functionality  such  as  providing  a  range  of  addresses  from  which  the 
authorized  external  entity  can  connect. 
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5.1.2 


TOE  Security  Assurance  Requirements 


90  The  assurance  security  requirements  for  this  Protection  Profile,  taken  from  Part  3 

of  the  CC,  compose  EAL2.  These  assurance  components  are  summarized  in  the 
following  table. 


Assurance  Class 

Assurance  Components 

Configuration  management 

ACM_CAP.2 

Configuration  items 

Delivery  and  operation 

ADO_DEL.l 

Delivery  procedures 

ADOJGS.l 

Installation,  generation,  and  start-up  procedures 

Development 

ADV_FSP.l 

Informal  functional  specification 

ADV_HLD.l 

Descriptive  high-level  design 

ADV_RCR.l 

Informal  correspondence  demonstration 

Guidance  documents 

AGD_ADM.l 

Administrator  guidance 

AGD_USR.l 

User  guidance 

Tests 

ATE_COV.l 

Evidence  of  coverage 

ATE_EUN.l 

Functional  testing 

ATE_IND.2 

Independent  testing  -  sample 

Vulnerability  assessment 

AVA_SOE.l 

Strength  of  TOE  security  function  evaluation 

AVA_VLA.l 

Developer  vulnerability  analysis 

Table  5.3  -  Assurance  Requirements:  EAL2 

ACM_CAP.2  Configuration  items 

Developer  action  elements: 


91  ACM_CAP.2.1D  -  The  developer  shall  provide  a  reference  for  the  TOE. 

92  ACM_CAP.2.2D  -  The  developer  shall  use  a  CM  system. 

93  ACM_CAP.2.3D  -  The  developer  shall  provide  CM  documentation. 

Content  and  presentation  of  evidence  elements: 

94  ACM_CAP.2.1C  -  The  reference  for  the  TOE  shall  be  unique  to  each  version  of 
the  TOE. 

95  ACM_CAP.2.2C  -  The  TOE  shall  be  labeled  with  its  reference. 

96  ACM_CAP.2.3C  -  The  CM  documentation  shall  include  a  configuration  list. 

97  ACM_CAP.2.4C  -  The  configuration  list  shall  describe  the  configuration  items 

that  comprise  the  TOE. 
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98  ACM_CAP.2.5C  -  The  CM  documentation  shall  describe  the  method  used  to 
uniquely  identify  the  configuration  items. 

99  ACM_CAP.2.6C  -  The  CM  system  shall  uniquely  identify  all  configuration  items. 
Evaluator  action  elements: 

100  ACM_CAP.2.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 

ADO_DEE.  1  Delivery  procedures 

Developer  action  elements: 

101  AD0_DEE.1.1D  -  The  developer  shall  document  procedures  for  delivery  of  the 
TOE  or  parts  of  it  to  the  user. 

102  ADO_DEE.1.2D  -  The  developer  shall  use  the  delivery  procedures. 

Content  and  presentation  of  evidence  elements: 

103  ADO_DEE.l.lC  -  The  delivery  documentation  shall  describe  all  procedures  that 
are  necessary  to  maintain  security  when  distributing  versions  of  the  TOE  to  a 
user’s  site. 

Evaluator  action  elements: 

104  ADO_DEE.l.lE  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 

ADO_IGS.  1  Installation,  generation,  and  start-up  procedures 

Developer  action  elements: 

105  ADO_IGS.l.lD  -  The  developer  shall  document  procedures  necessary  for  the 
secure  installation,  generation,  and  start-up  of  the  TOE. 

Content  and  presentation  of  evidence  elements: 

106  ADO_IGS.l.lC  -  The  documentation  shall  describe  the  steps  necessary  for  secure 
installation,  generation,  and  start-up  of  the  TOE. 

Evaluator  action  elements: 

107  ADO_IGS.l.lE  -  The  evaluator  shall  confirm  that  the  information  provided  meets 
all  requirements  for  content  and  presentation  of  evidence. 

ADO_IGS.1.2E  -  The  evaluator  shall  determine  that  the  installation,  generation, 
and  start-up  procedures  result  in  a  secure  configuration. 


108 
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ADV_FSP.l  Informal  functional  specification 


Developer  action  elements: 

109  ADV_FSP.1.1D  -  The  developer  shall  provide  a  functional  specification. 

Content  and  presentation  of  evidence  elements: 

110  ADV_FSP.1.1C  -  The  functional  specification  shall  describe  the  TSF  and  its 
external  interfaces  using  an  informal  style. 

1 1 1  ADV_FSP.  1 .2C  -  The  functional  specification  shall  be  internally  consistent. 

112  ADV_FSP.1.3C  -  The  functional  specification  shall  describe  the  purpose  and 

method  of  use  of  all  external  TSF  interfaces,  providing  details  of  effects, 

exceptions  and  error  messages,  as  appropriate. 

113  ADV_FSP.1.4C  -  The  functional  specification  shall  completely  represent  the  TSF. 
Evaluator  action  elements: 

1 14  ADV_FSP. TIE  -  The  evaluator  shall  confirm  that  the  information  provided  meets 
all  requirements  for  content  and  presentation  of  evidence. 

115  ADV_ESP.1.2E  -  The  evaluator  shall  determine  that  the  functional  specification  is 
an  accurate  and  complete  instantiation  of  the  TOE  security  functional 
requirements. 

116  Application  Note:  This  requirement  can  potentially  be  met  by  a  combination 

of  documents  provided  by  the  developer,  including  the  Security  Target  and 
external  interface  specification. 

ADV_HED.  1  Descriptive  high-level  design 
Developer  action  elements: 

1 17  ADV_HED.  1 .  ID  -  The  developer  shall  provide  the  high-level  design  of  the  TSE. 
Content  and  presentation  of  evidence  elements: 

118  ADV_HED.  1 . 1C  -  The  presentation  of  the  high-level  design  shall  be  informal. 

1 19  ADV_HED.  1 .2C  -  The  high-level  design  shall  be  internally  consistent. 

120  ADV_HED.1.3C  -  The  high-level  design  shall  describe  the  structure  of  the  TSE  in 
terms  of  subsystems. 

121  ADV_HED.1.4C  -  The  high-level  design  shall  describe  the  security  functionality 
provided  by  each  subsystem  of  the  TSE. 
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ADV_HLD.1.5C  -  The  high-level  design  shall  identify  any  underlying  hardware, 
firmware,  and/or  software  required  by  the  TSF  with  a  presentation  of  the 
functions  provided  by  the  supporting  protection  mechanisms  implemented  in  that 
hardware,  firmware,  or  software. 

123  ADV_HLD.1.6C  -  The  high-level  design  shall  identify  all  interfaces  to  the 
subsystems  of  the  TSF. 

124  ADV_HLD.1.7C  -  The  high-level  design  shall  identify  which  of  the  interfaces  to 
the  subsystems  of  the  TSF  are  externally  visible. 

Evaluator  action  elements: 

125  ADV_HLD.1.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 

126  ADV_HED.1.2E  -  The  evaluator  shall  determine  that  the  high-level  design  is  an 
accurate  and  complete  instantiation  of  the  TOE  security  functional  requirements. 

127  Requirements  Overview:  ADV_RCR.l  ensures  that  there  is  consistency 

between  each  level  of  design  decomposition  for  the  TOE.  Each  higher  level  of 
design  decomposition  (the  higher  the  level  of  design  decomposition,  the  more 
abstract)  should  map  to  the  one  below  it,  until  a  level  of  design  decomposition 
maps  to  the  least  abstract  representation,  the  implementation  itself.  Thus,  for 
Security  Targets  derived  from  this  Protection  Profile  there  are  four  layers  of 
abstraction  (from  high  to  low):  the  Sts  “TOE  summary  specification”  section,  the 
Eunctional  Specification,  the  high-level  design,  and  the  TOE  itself."^ 

ADV_RCR.l  Informal  correspondence  demonstration 
Developer  action  elements: 

128  ADV_RCR.1.1D  -  The  developer  shall  provide  an  analysis  of  correspondence 
between  all  adjacent  pairs  of  TSE  representations  that  are  provided. 

Content  and  presentation  of  evidence  elements: 

129  ADV_RCR.1.1C  -  Eor  each  adjacent  pair  of  provided  TSE  representations,  the 
analysis  shall  demonstrate  that  all  relevant  security  functionality  of  the  more 
abstract  TSE  representation  is  correctly  and  completely  refined  in  the  less  abstract 
TSE  representation. 


For  related  information,  see  section  4.2.1  in  Part  1  of  the  CC. 
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Evaluator  action  elements: 


130  ADV_RCR.1.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 

131  Application  Note:  The  intent  of  this  requirement  is  for  the  vendor  to  provide, 

and  the  evaluator  to  confirm,  that  there  exists  accurate,  consistent,  and  clear 
mappings  between  each  level  of  design  decomposition.  Thus  there  can  be  no  TOE 
security  functions  defined  at  a  lower  layer  of  abstraction  absent  from  a  higher 
level  of  abstraction  and  vice  versa. 

AGD_ADM.  1  Administrator  guidance 

Developer  action  elements: 

132  AGD_ADM.1.1D  -  The  developer  shall  provide  administrator  guidance  addressed 
to  system  administrative  personnel. 

Content  and  presentation  of  evidence  elements: 

133  AGD_ADM.1.1C  -  The  administrator  guidance  shall  describe  the  administrative 
functions  and  interfaces  available  to  the  administrator  of  the  TOE. 

134  AGD_ADM.1.2C  -  The  administrator  guidance  shall  describe  how  to  administer 
the  TOE  in  a  secure  manner. 

135  AGD_ADM.1.3C  -  The  administrator  guidance  shall  contain  warnings  about 
functions  and  privileges  that  should  be  controlled  in  a  secure  processing 
environment. 

136  AGD_ADM.1.4C  -  The  administrator  guidance  shall  describe  all  assumptions 
regarding  user  behavior  that  are  relevant  to  secure  operation  of  the  TOE. 

137  AGD_ADM.1.5C  -  The  administrator  guidance  shall  describe  all  security 
parameters  under  the  control  of  the  administrator,  indicating  secure  values  as 
appropriate. 

138  AGD_ADM.1.6C  -  The  administrator  guidance  shall  describe  each  type  of 
security-relevant  event  relative  to  the  administrative  functions  that  need  to  be 
performed,  including  changing  the  security  characteristics  of  entities  under  the 
control  of  the  TSE. 

139  AGD_ADM.1.7C  -  The  administrator  guidance  shall  be  consistent  with  all  other 
documentation  supplied  for  evaluation. 

140  AGD_ADM.1.8C  -  The  administrator  guidance  shall  describe  all  security 
requirements  for  the  IT  environment  that  are  relevant  to  the  administrator. 
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Evaluator  action  elements: 


141  AGD_ADM.1.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 

AGD_USR.  1  User  guidance 

Developer  action  elements: 

142  AGD_USR.  1 .  ID  -  The  developer  shall  provide  user  guidance. 

Content  and  presentation  of  evidence  elements: 

143  AGD_USR.1.1C  -  The  user  guidance  shall  describe  the  functions  and  interfaces 
available  to  the  non-administrative  users  of  the  TOE. 

144  AGD_USR.1.2C  -  The  user  guidance  shall  describe  the  use  of  user-accessible 
security  functions  provided  by  the  TOE. 

145  AGD_USR.1.3C  -  The  user  guidance  shall  contain  warnings  about  user-accessible 
functions  and  privileges  that  should  be  controlled  in  a  secure  processing 
environment. 

146  AGD_USR.1.4C  -  The  user  guidance  shall  clearly  present  all  user  responsibilities 
necessary  for  secure  operation  of  the  TOE,  including  those  related  to  assumptions 
regarding  user  behavior  found  in  the  statement  of  TOE  security  environment. 

147  AGD_USR.1.5C  -  The  user  guidance  shall  be  consistent  with  all  other 
documentation  supplied  for  evaluation. 

148  AGD_USR.1.6C  -  The  user  guidance  shall  describe  all  security  requirements  for 
the  IT  environment  that  are  relevant  to  the  user. 

Evaluator  action  elements: 

149  AGD_USR.1.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 

150  Application  Note:  This  assurance  component  is  trivially  met  if  neither 

authorized  external  IT  entities  nor  human  users  who  are  not  authorized 
administrators  are  permitted  on  the  TOE.  If  authorized  external  IT  entities  and/or 
human  users  who  are  not  authorized  administrators  are  permitted  on  the  TOE,  it  is 
intended  that  functions  and  interfaces  for  these  users  be  described.  If  the 
developer  permits  human  users  who  are  not  authorized  administrators  on  the 
TOE,  AGD_USR.1.2C  is  not  intended  to  permit  security  functions  or  interfaces  to 
exist  for  such  users  beyond  those  security  functions  described  in  the  CC  class  EIA 
functional  components  in  section  5.1.1.  If  the  developer  does  not  permit  human 
users  who  are  not  authorized  administrators  on  the  TOE,  AGD_USR.1.2C  only 
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applies  if  authorized  external  IT  entities  are  permitted. 


ATE_COV.l  Evidence  of  coverage 

Developer  action  elements: 

151  ATE_C0V.1.1D  -  The  developer  shall  provide  evidence  of  the  test  coverage. 
Content  and  presentation  of  evidence  elements: 

152  ATE_C0V.1.1C  -  The  evidence  of  the  test  coverage  shall  show  the 
correspondence  between  the  tests  identified  in  the  test  documentation  and  the  TSE 
as  described  in  the  functional  specification. 

Evaluator  action  elements: 

153  ATE_C0V.1.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 

ATE_EUN.l  Eunctional  testing 

Developer  action  elements: 

154  ATE_EUN.  1 . ID  -  The  developer  shall  test  the  TSE  and  document  the  results. 

155  ATE_EUN.  1 .2D  -  The  developer  shall  provide  test  documentation. 

Content  and  presentation  of  evidence  elements: 

156  ATE_EUN.1.1C  -  The  test  documentation  shall  consist  of  test  plans,  test 
procedure  descriptions,  expected  test  results  and  actual  test  results. 

157  ATE_EUN.1.2C  -  The  test  plans  shall  identify  the  security  functions  to  be  tested 
and  describe  the  goal  of  the  tests  to  be  performed. 

158  ATE_EUN.1.3C  -  The  test  procedure  descriptions  shall  identify  the  tests  to  be 
performed  and  describe  the  scenarios  for  testing  each  security  function.  These 
scenarios  shall  include  any  ordering  dependencies  on  the  results  of  other  tests. 

159  ATE_EUN.1.4C  -  The  expected  test  results  shall  show  the  anticipated  outputs 
from  a  successful  execution  of  the  tests. 

160  ATE_EUN.1.5C  -  The  test  results  from  the  developer  execution  of  the  tests  shall 
demonstrate  that  each  tested  security  function  behaved  as  specified. 

Evaluator  action  elements: 

161  ATE_EUN.1.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 
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ATE  IND.2 


Independent  testing  -  sample 
Developer  action  elements: 

162  ATE_IND.2.1D  -  The  developer  shall  provide  the  TOE  for  testing. 

Content  and  presentation  of  evidence  elements: 

163  ATE_IND.2.1C  -  The  TOE  shall  be  suitable  for  testing. 

164  ATE_IND.2.2C  -  The  developer  shall  provide  an  equivalent  set  of  resources  to 
those  that  were  used  in  the  developer’s  functional  testing  of  the  TSE. 

Evaluator  action  elements: 

165  ATE_IND.2.1E  -  The  evaluator  shall  confirm  that  the  information  provided  meets 
all  requirements  for  content  and  presentation  of  evidence. 

166  ATE_IND.2.2E  -  The  evaluator  shall  test  a  subset  of  the  TSE  as  appropriate  to 
confirm  that  the  TOE  operates  as  specified. 

167  ATE_IND.2.3E  -  The  evaluator  shall  execute  a  sample  of  tests  in  the  test 
documentation  to  verify  the  developer  test  results. 

AVA_SOE.  1  Strength  of  TOE  security  function  evaluation^ 

Developer  action  elements: 

168  AVA_S0E.1.1D  -  The  developer  shall  perform  a  strength  of  TOE  security 
function  analysis  for  each  mechanism  identified  in  the  ST  as  having  a  strength  of 
TOE  security  function  claim. 

Content  and  presentation  of  evidence  elements: 

169  AVA_S0E.1.1C  -  Eor  each  mechanism  with  a  strength  of  TOE  security  function 
claim  the  strength  of  TOE  security  function  analysis  shall  show  that  it  meets  or 
exceeds  the  minimum  strength  level  defined  in  the  PP/ST. 

170  AVA_SOP.1.2C  -  Eor  each  mechanism  with  a  specific  strength  of  TOE  security 
function  claim  the  strength  of  TOE  security  function  analysis  shall  show  that  it 
meets  or  exceeds  the  specific  strength  of  function  metric  defined  in  the  PP/ST. 


This  component  is  intended  to  apply  strictly  to  those  security  functions  that  are  vulnerable  to  an  attack 
involving  a  quantitative  or  statistical  analysis  (e.g.,  password  guessing).  A  short  discussion  of  how  a 
security  mechanism  may  be  vulnerable  is  provided  under  the  “Objectives”  heading  for  AVA_SOF,  in  Part 
3  of  the  CC. 
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Evaluator  action  elements: 


171  AVA_S0F.1.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 

172  AVA_SOE.  1.2E  -  The  evaluator  shall  confirm  that  the  strength  claims  are  correct. 

173  Application  Note:  The  security  mechanisms  defined  by  the  following 

requirements  have  a  specific  strength  of  function  claim:  FIA_UAU.5.  Section 
5.1.1  of  this  PP  defines  the  specific  strength  of  function  metric  for  each  of  these 
mechanisms. 

AVA_VEA.l  Developer  vulnerability  analysis 
Developer  action  elements: 

174  AVA_VEA.1.1D  -  The  developer  shall  perform  and  document  an  analysis  of  the 
TOE  deliverables  searching  for  obvious  ways  in  which  a  user  can  violate  the  TSP. 

175  AVA_VEA.1.2D  -  The  developer  shall  document  the  disposition  of  obvious 
vulnerabilities. 

Content  and  presentation  of  evidence  elements: 

176  AVA_VEA.1.1C  -  The  documentation  shall  show,  for  all  identified 
vulnerabilities,  that  the  vulnerability  cannot  be  exploited  in  the  intended 
environment  for  the  TOE. 

Evaluator  action  elements: 

177  AVA_VEA.1.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 

178  AVA_VEA.  1 .2E  -  The  evaluator  shall  conduct  penetration  testing,  building  on  the 
developer  vulnerability  analysis,  to  ensure  obvious  vulnerabilities  have  been 
addressed. 

179  Application  Note:  According  to  the  Common  Criteria  Part  3,  obvious 

vulnerabilities  include  those  in  the  public  domain.  The  evaluation  body  will  be 
provided  a  current  list  of  such  vulnerabilities  which  should  be  included  as  part  of 
vulnerability  analysis  and  penetration  testing.  The  first  instantiation  of  this  list  is 
call  Vulnerability  list  for  AVA_VEA.l  and  is  included  as  Appendix  A  of  this 
document. 
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6 


RATIONALE 


6.1 

O.IDAUTH 

O.SINUSE 

O.MEDIAT 

O.SECSTA 

O.ENCRYP 

O.SEEPRO 

O.AUDREC 

O.ACCOUN 

O.SECEUN 


RATIONALE  FOR  IT  SECURITY  OBJECTIVES 

This  security  objective  is  necessary  to  counter  the  threat:  T.NOAUTH  because  it 
requires  that  users  be  uniquely  identified  before  accessing  the  TOE. 

This  security  objective  is  necessary  to  counter  the  threats:  T.REPEAT  and 
T.REPEAY  because  it  requires  that  the  TOE  prevent  the  reuse  of  authentication 
data  so  that  even  if  valid  authentication  data  is  obtained,  it  will  not  be  used  to 
mount  an  attack. 

This  security  objective  is  necessary  to  counter  the  threats:  T.ASPOOE, 
T.MEDIAT  and  T.OEDINE  which  have  to  do  with  getting  impermissible 
information  to  flow  through  the  TOE.  This  security  objective  requires  that  all 
information  that  passes  through  the  networks  is  mediated  by  the  TOE  and  that  no 
residual  information  is  transmitted. 

This  security  objective  ensures  that  no  information  is  compromised  by  the  TOE 
upon  start-up  or  recovery  and  thus  counters  the  threats:  T.NOAUTH  and 
T.SEEPRO. 

This  security  objective  is  necessary  to  counter  the  threats  and  policy: 

T.NOAUTH,  T.PROCOM  and  P.CRYPTO  by  requiring  that  an  authorized 
administrator  use  encryption  when  performing  administrative  functions  on  the 
TOE  remotely. 

This  security  objective  is  necessary  to  counter  the  threats:  T.SEEPRO, 

T.AUDEUE  and  T.NOAUTH  because  it  requires  that  the  TOE  protect  itself  from 
attempts  to  bypass,  deactivate,  or  tamper  with  TOE  security  functions. 

This  security  objective  is  necessary  to  counter  the  threat:  T.AUDACC  by 
requiring  a  readable  audit  trail  and  a  means  to  search  and  sort  the  information 
contained  in  the  audit  trail. 

This  security  objective  is  necessary  to  counter  the  threat:  T.AUDACC  because  it 
requires  that  users  are  accountable  for  information  flows  through  the  TOE  and 
that  authorized  administrators  are  accountable  for  the  use  of  security  functions 
related  to  audit. 

This  security  objective  is  necessary  to  counter  the  threats:  T.NOAUTH, 

T.REPEAY  and  T.AUDEUE  by  requiring  that  the  TOE  provide  functionality  that 
ensures  that  only  the  authorized  administrator  has  access  to  the  TOE  security 
functions. 
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O.LIMEXT  This  security  objective  is  necessary  to  counter  the  threat:  T.NOAUTH  because  it 
requires  that  the  TOE  provide  the  means  for  an  authorized  administrator  to  control 
and  limit  access  to  TOE  security  functions. 

O.EAE  This  security  objective  is  necessary  to  counter  the  threat:  T.EOWEXP  because  it 

requires  that  the  TOE  is  resistant  to  penetration  attacks  performed  by  an  attacker 
possessing  minimal  attack  potential. 


T.NOAUTH 

T.REPEAT 

T.REPEAY 

T.ASPOOE 

T.MEDIAT 

T.OEDINE 

T.PROCOM 

T.AUDACC 

T.SEEPRO 

T.AUDEUE 

T.EOWEXP 

P.CRYPTPO 

O.IDAUTH 

X 

O.SINUSE 

X 

X 

O.MEDIAT 

X 

X 

X 

O.SECSTA 

X 

X 

O.ENCRYP 

X 

X 

X 

O.SEEPRO 

X 

X 

X 

O.AUDREC 

X 

O.ACCOUN 

X 

O.SECEUN 

X 

X 

X 

O.EIMEXT 

X 

O.EAE 

X 

Table  6.1  -  Summary  of  Mappings  Between  Threats  and  IT  Security 

Objectives 

6.2  RATIONALE  FOR  SECURITY  OBJECTIVES  FOR  THE 

ENVIRONMENT 


O.PHYSEC  The  TOE  is  physically  secure. 

O.EOWEXP  The  threat  of  malicious  attacks  aimed  at  discovering  exploitable  vulnerabilities  is 
considered  low. 


O.GENPUR  There  are  no  general-purpose  computing  capabilities  (e.g.,  the  ability  to  execute 
arbitrary  code  or  applications)  and  storage  repository  capabilities  on  the  TOE. 
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O.PUBLIC 

O.NOEVIL 

O.SINGEN 

O.DIRECT 

O.NOREMO 

O.REMACC 

O.GUIDAN 

O.ADMTRA 


180 

6.3 

181 


The  TOE  does  not  host  public  data. 

Authorized  administrators  are  non-hostile  and  follow  all  administrator  guidance; 
however,  they  are  capable  of  error. 

Information  can  not  flow  among  the  internal  and  external  networks  unless  it 
passes  through  the  TOE. 

Human  users  within  the  physically  secure  boundary  protecting  the  TOE  may 
attempt  to  access  the  TOE  from  some  direct  connection  (e.g.,  a  console  port)  if 
the  connection  is  part  of  the  TOE. 

Human  users  who  are  not  authorized  administrators  can  not  access  the  TOE 
remotely  from  the  internal  or  external  networks. 

Authorized  administrators  may  access  the  TOE  remotely  from  the  internal  and 
external  networks. 

This  non-IT  security  objective  is  necessary  to  counter  the  threat:  T.TUSAGE  and 
T.AUDACC  because  it  requires  that  those  responsible  for  the  TOE  ensure  that  it 
is  delivered,  installed,  administered,  and  operated  in  a  secure  manner. 

This  non-IT  security  objective  is  necessary  to  counter  the  threat:  T.TUSAGE  and 
T.AUDACC  because  it  ensures  that  authorized  administrators  receive  the  proper 
training. 


T.TUSAGE 

T.AUDACC 

O.GUIDAN 

X 

X 

O.ADMTRA 

X 

X 

Table  6.2  -  Summary  of  Mappings  Between  Threats  and 
Security  Objectives  for  the  Environment 


Since  the  rest  of  the  security  objectives  for  the  environment  are,  in  part,  a  re¬ 
statement  of  the  security  assumptions,  those  security  objectives  trace  to  all  aspects 
of  the  assumptions. 

RATIONALE  FOR  SECURITY  REQUIREMENTS 

The  security  requirements  are  derived  according  to  the  general  model  presented  in 
Part  1  of  the  Common  Criteria.  Specifically,  Table  6.3  illustrates  the  mapping 
between  the  security  requirements  and  the  security  objectives  and  Table  6.1 
demonstrates  the  relationship  between  the  threats,  policies  and  IT  security 
objectives.  The  functional  and  assurance  requirements  presented  in  this 
Protection  Profile  are  mutually  supportive  and  their  combination  meet  the  stated 
security  objectives. 
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FMT_SMR.l 

183 


FIA_ATD.l 

184 


FIA_UID.2 
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FIA_AFL.l 
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FIA_UAU.5 
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FDPJFC.l 
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The  rationale  for  the  SOF  is  based  on  the  minimal  attack  potential  identified  in 
this  Protection  Profile.  The  security  objectives  imply  the  need  for  probablistic  or 
permutational  security  mechanisms.  The  metrics  defined  in  this  Protection  Profile 
are  acceptable  (i.e.,  passwords)  metrics  to  protect  information  in  environments 
which  process,  at  most,  sensitive  but  unclassified  information,  or  the  sensitivity 
level  of  information  in  both  the  internal  and  external  networks  is  equivalent. 

Security  roles 

Each  of  the  CC  class  FMT  components  in  this  Protection  Profile  depends  on  this 
component.  It  requires  the  PP/ST  writer  to  choose  a  role(s).  This  component 
traces  back  to  and  aids  in  meeting  the  following  objective:  O.SECFUN. 

User  attribute  definition 

This  component  exists  to  provide  users  with  attributes  to  distinguish  one  user 
from  another,  for  accountability  purposes  and  to  associate  the  role  chosen  in 
EMT_SMR.l  with  a  user.  This  component  traces  back  to  and  aids  in  meeting  the 
following  objectives:  O.IDAUTH  and  O.SECEUN. 

User  identification  before  any  action 

This  component  ensures  that  before  anything  occurs  on  behalf  of  a  user,  the  user's 
identity  is  identified  to  the  TOE.  This  component  traces  back  to  and  aids  in 
meeting  the  following  objectives:  O.IDAUTH  and  O.ACCOUN. 

Authentication  failure  handling 

This  component  ensures  that  human  users  who  are  not  authorized  administrators 
can  not  endlessly  attempt  to  authenticate.  After  some  number  of  failures  that  the 
authorized  administrator  decides,  that  must  not  be  zero,  the  user  becomes  unable 
from  that  point  on  in  attempts  to  authenticate.  This  goes  on  until  an  authorized 
administrator  makes  authentication  possible  again  for  that  user.  This  component 
traces  back  to  and  aids  in  meeting  the  following  objective:  O.SEEPRO. 

Multiple  authentication  mechanisms 

This  component  was  chosen  to  ensure  that  multiple  authentication  mechanism  are 
used  appropriately  in  all  attempts  to  authenticate  at  the  TOE  from  an  internal  or 
external  network.  A  SOE  metric  for  this  requirement  is  defined  in  section  5.1.1  to 
ensure  that  the  mechanisms  are  of  adequate  probabilistic  strength  to  protect 
against  authentication  data  compromise.  This  component  traces  back  to  and  aids 
in  meeting  the  following  objective:  O.SINUSE  and  O.IDAUTH. 

Subset  information  flow  control  (1) 

This  component  identifies  the  entities  involved  in  the  UNAUTHENTICATED 
information  flow  control  SEP  (i.e.,  users  sending  information  to  other  users  and 
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vice  versa).  This  component  traces  back  to  and  aids  in  meeting  the  following 
objective:  O.MEDIAT. 

FDP_IFC.l  Subset  information  flow  control  (2) 

189  This  component  identifies  the  entities  involved  in  the  AUTHENTICATED 
information  flow  control  SEP  (i.e.,  users  of  the  services  FTP  or  Telnet  sending 
information  to  servers  and  vice  versa).  The  users  of  these  services  must  be 
authenticated  at  the  TOE.  This  component  traces  back  to  and  aids  in  meeting  the 
following  objective:  O.MEDIAT. 

FDP_IFF.l  Simple  security  attributes  (1) 

190  This  component  identifies  the  attributes  of  the  users  sending  and  receiving  the 
information  in  the  UNAUTHENTICAED  SEP,  as  well  as  the  attributes  for  the 
information  itself.  Then  the  policy  is  defined  by  saying  under  what  conditions 
information  is  permitted  to  flow.  This  component  traces  back  to  and  aids  in 
meeting  the  following  objective:  O.MEDIAT. 

FDP_IFF.  1  Simple  security  attributes  (2) 

191  This  component  identifies  the  attributes  of  the  users  sending  and  receiving  the 
information  in  the  AUTHENTICAED  SEP,  as  well  as  the  attributes  for  the 
information  itself.  Then  the  policy  is  defined  by  saying  under  what  conditions 
information  is  permitted  to  flow.  This  component  traces  back  to  and  aids  in 
meeting  the  following  objective:  O.MEDIAT. 

FMT_MSA.l  Management  of  security  attributes  (1) 

192  This  component  ensures  the  TSF  enforces  the  UNAUTHENTICATED_SFP  to 
restrict  the  ability  to  delete,  modify,  and  add  within  a  rule  those  security  attributes 
that  are  listed  in  section  ED P_IFF  1.1(1).  This  component  traces  back  to  and  aids 
in  meeting  the  following  objectives:  O.MEDIAT,  O.SECSTA,  and  O.SECFUN. 

FMT_MSA.l  Management  of  security  attributes  (2) 

193  This  component  ensures  the  TSF  enforces  the  AUTHENTICATED_SFP  to 
restrict  the  ability  to  delete,  modify,  and  add  within  a  rule  those  specified  security 
attributes  that  are  listed  in  section  FDP_IFF  1.1(2).  This  component  traces  back  to 
and  aids  in  meeting  the  following  objectives:  O.MEDIAT,  O.SECSTA,  and 
O.SECFUN. 

FMT_MSA.l  Management  of  security  attributes  (3) 

194  This  component  ensures  the  TSF  enforces  the  UNAUTHENTICATED_SFP  to 
restrict  the  ability  to  create  or  delete  rules  for  security  attributes  that  are  listed  in 
FDP_IFF.1(1).  This  component  traces  back  to  and  aids  in  meeting  the  following 
objectives:  O.MEDIAT,  O.SECSTA,  and  O.SECFUN. 
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FMT_MSA.l  Management  of  security  attributes  (4) 

195  This  component  ensures  the  TSF  enforces  the  AUTHENTICATED_SFP  to 
restrict  the  ability  to  create  or  delete  rules  for  security  attributes  that  are  listed  in 
EDP_IEE.1(2).  This  component  traces  back  to  and  aids  in  meeting  the  following 
objectives:  O.MEDIAT,  O.SECSTA,  and  O.SECEUN. 

PMT_MSA.3  Static  attribute  initialization 

196  This  component  ensures  that  there  is  a  default  deny  policy  for  the  information 
flow  control  security  rules.  This  component  traces  back  to  and  aids  in  meeting  the 
following  objectives:  O.MEDIAT  andO.SECSTA. 

EMT_MTD.l  Management  of  TSE  data  (1) 

197  This  component  ensures  that  the  TSE  restrict  abilities  to  query,  modify,  delete  and 
assign  certain  user  attributes  as  defined  in  EIA_ATD.1.1  to  only  the  authorized 
administrator.  This  component  traces  back  to  and  aids  in  meeting  the  following 
objective:  O.SECEUN. 

EMT_MTD.l  Management  of  TSE  data  (2) 

198  This  component  ensures  that  the  TSE  restrict  abilities  to  set  the  time  and  date  used 
to  form  timestamps  to  only  the  authorized  administrator.  This  component  traces 
back  to  and  aids  in  meeting  the  following  objective:  O.SECEUN. 

EMT_MTD.2  Management  of  limits  on  TSE  data 

199  This  component  ensures  that  the  TSE  restrict  the  specification  of  limits  of  the 
number  of  unauthenticated  failures  to  the  authorized  administrator  and  specifies 
the  action  be  taken  if  limits  on  the  TSE  data  are  reached  or  exceeded.  This 
component  traces  back  to  and  aids  in  meeting  the  following  objective: 
O.SECEUN. 

EDP_RIP.  1  Subset  residual  information  protection 

200  This  component  ensures  that  neither  information  that  had  flown  through  the  TOE 
nor  any  TOE  internal  data  are  used  when  padding  is  used  by  the  TOE  for 
information  flows.  This  component  traces  back  to  and  aids  in  meeting  the 
following  objective:  O.MEDIAT. 

EC  S_C  OP .  I  Cryptographic  operation 

201  This  component  ensures  that  if  the  TOE  does  support  authorized  administrators  to 
communicate  with  the  TOE  remotely  from  an  internal  or  external  network  that 
DES  is  used  to  encrypt  such  traffic.  This  component  traces  back  to  and  aids  in 
meeting  the  following  objective:  O.ENCRYP  and  O.EAE. 
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FPT_RVM.l  Non-bypassability  of  the  TSP 

202  This  component  ensures  that  the  TSF  are  always  invoked.  This  component  traces 
back  to  and  aids  in  meeting  the  following  objective:  O.SELPRO  and  O.SECSTA. 

EPT_SEP.l  TSE  domain  separation 

203  This  component  ensures  that  the  TSE  have  a  domain  of  execution  that  is  separate 
and  that  cannot  be  violated  by  unauthorized  users.  This  component  traces  back  to 
and  aids  in  meeting  the  following  objective:  O.SEEPRO  and  O.SECSTA. 

EPT_STM.l  Reliable  time  stamps 

204  EAU_GEN.  1  depends  on  this  component.  It  ensures  that  the  date  and  time  on  the 
TOE  is  dependable.  This  is  important  for  the  audit  trail.  This  component  traces 
back  to  and  aids  in  meeting  the  following  objective:  O.AUDREC. 

EAU_GEN.  1  Audit  data  generation 

205  This  component  outlines  what  data  must  be  included  in  audit  records  and  what 
events  must  be  audited.  This  component  traces  back  to  and  aids  in  meeting  the 
following  objectives:  O.AUDREC  and  O.ACCOUN. 

EAU_SAR.l  Audit  review 

206  This  component  ensures  that  the  audit  trail  is  understandable.  This  component 
traces  back  to  and  aids  in  meeting  the  following  objective:  O.AUDREC. 

EAU_SAR.3  Selectable  audit  review 

207  This  component  ensures  that  a  variety  of  searches  and  sorts  can  be  performed  on 
the  audit  trail.  This  component  traces  back  to  and  aids  in  meeting  the  following 
objective:  O.AUDREC. 

EAU_STG.  1  Protected  audit  trail  storage 

208  This  component  is  chosen  to  ensure  that  the  audit  trail  is  protected  from 
tampering,  the  security  functionality  is  limited  to  the  authorized  administrator, 
and  that  start-up  and  recovery  does  not  compromise  the  audit  records.  This 
component  traces  back  to  and  aids  in  meeting  the  following  objectives: 
O.SEEPRO,  O.SECEUN  and  O.SECSTA. 

EAU_STG.4  Prevention  of  audit  data  loss 

209  This  component  ensures  that  the  authorized  administrator  will  be  able  to  take  care 
of  the  audit  trail  if  it  should  become  full.  But  this  component  also  ensures  that  no 
other  auditable  events  as  defined  in  PAU_GEN.l  occur.  Thus  the  authorized 
administrator  is  permitted  to  perform  potentially  auditable  actions  though  these 
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events  will  not  be  recorded  until  the  audit  trail  is  restored  to  a  non-full  status.  This 
component  traces  back  to  and  aids  in  meeting  the  following  objectives: 
O.SELPRO,  O.SECFUN  and  O.SECSTA. 

EMT_MOE.  1  Management  of  security  functions  behavior  (1) 

210  This  component  was  to  ensure  the  TSF  restricts  the  ability  of  the  TOE  start  up  and 
shut  down  operation  and  multiple  authentication  function  to  the  authorized 
administrator.  This  component  traces  back  to  and  aids  in  meeting  the  following 
objectives:  O.SECFUN,  O.EIMEXT,  and  O.SECSTA. 

FMT_MOF.  1  Management  of  security  functions  behavior  (2) 

211  This  component  was  to  ensure  the  TSF  restricts  the  ability  to  modify  the  behavior 
of  functions  such  as  audit  trail  management,  back  and  restore  for  TSF  data,  and 
communication  of  authorized  external  IT  entities  with  the  TOE  to  an  authorized 
administrator.  This  component  traces  back  to  and  aids  in  meeting  the  following 
objectives:  O.SECFUN,  O.EIMEXT,  and  O.SECSTA. 
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Table  6.3  -  Summary  of  Mappings  Between  Threats  and  IT 
Security  Objectives 


O.LIMEXT 


6.4 


RATIONALE  FOR  ASSURANCE  REQUIREMENTS 


212  EAL2  was  chosen  to  ensure  a  level  of  security  in  the  absence  of  complete  vendor 
documentation.  Specifically,  the  assurance  requirements  (that  is,  documentation 
and  testing)  were  chosen  to  demonstrate  that  a  low  to  moderate  level  of 
independently  assured  security  exists  as  defined  in  Part  3,  Section  6.2.2  of  the  CC. 
Minimal  additional  tasks  are  imposed  upon  the  vendor  to  the  extent  that  if  the 
vendor  applies  reasonable  standards  of  care  to  the  development,  evaluation  may 
be  feasible  without  vendor  involvement  other  than  support  for  functional  testing, 
strength  of  function  analysis  and  vulnerability  testing  verification. 

213  The  chosen  assurance  level  is  consistent  with  the  postulated  threat  environment. 
Specifically,  the  threat  of  malicious  attacks  aimed  at  discovering  exploitable 
vulnerabilities  is  considered  low,  and  the  product  will  have  undergone  a  search 
for  obvious  flaws.  This  is  supported  by  the  inclusion  of  the  AVA_VLA.l 
requirement. 

6.5  RATIONALE  FOR  NOT  SATISFYING  ALL  DEPENDENCIES 

214  With  the  exception  of  the  functional  component  FCS_COP.  1,  all  dependencies  are 
contained  in  this  Protection  Profile. 

215  Functional  component  FCS_COP.l  depends  on  the  following  functional 

components:  FCS_CKM.l  Cryptographic  key  generation,  FCS_CKM.4 

Cryptographic  key  destruction  and  FMT_MSA.2  Secure  Security  Attributes. 
Cryptographic  modules  must  be  FIPS  PUB  140-1  compliant.  If  the  cryptographic 
module  is  indeed  compliant  with  this  FIPS  PUB,  then  the  dependencies  of  key 
generation,  key  destruction  and  secure  key  values  will  have  been  satisfied  in 
becoming  FIPS  PUB  140- 1  compliant.  For  more  information,  refer  to  sections 
4.8.1  and  4.8.5  of  FIPS  PUB  I40-I. 
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Acronyms 
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The  following  abbreviations  from  the  Common  Criteria  are  used  in  this  Protection 
Profile: 


CC 

EAL 

FIPS  PUB 

IT 

PP 

SEP 

ST 

TOE 

TSC 

TSF 

TSP 


Common  Criteria  for  Information  Technology  Security  Evaluation 
Evaluation  Assurance  Eevel 

Eederal  Information  Processing  Standard  Publication 

Information  Technology 

Protection  Profile 

Security  Eunction  Policy 

Security  Target 

Target  of  Evaluation 

TSE  Scope  of  Control 

TOE  Security  Eunctions 

TOE  Security  Policy 
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